Implementing ICE for Media Sessions

The device supports Interactive Connectivity Establishment (ICE) for SBC calls. ICE is a methodology for NAT traversal, enabling VoIP interoperability across networks to work better across NATs and firewalls. It employs Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) protocols to provide a peer with a public IP address and port that can be used to connect to a remote peer. Therefore, for some applications such as when the device operates in Microsoft Teams Direct Routing (media bypass) environments, ICE is required.

For clients behind NATs and/or firewalls to send media (RTP) between one another, they need to discover each others IP address and port as seen by the "outside" world. If both peers are in different private networks behind a NAT, the peers must coordinate to determine the best communication path between them.

ICE first tries to make a connection using the client's private local address. If that fails (which it will for clients behind NAT), ICE obtains an external (public) address using a STUN server. If that fails, traffic is routed through a TURN relay server (which has a public address).

These addresses:ports (local, STUN, TURN and any other network address) of the client are termed "candidates". Each client sends its' candidates to the other in the SDP body of the SIP message (e.g., INVITE). Peers then perform connectivity checks per candidate of the other peer, using STUN binding requests sent on the RTP and RTCP ports. ICE tries each candidate and selects the one that works (i.e., media can flow between the clients).

The following figure provides a simple illustration of ICE:

The device supports ICE-Lite and ICE-Full (or ICE Full):

■

ICE-Lite: When configured for ICE-Lite, the device doesn't initiate the ICE process. Instead, it supports remote endpoints that initiate ICE to discover their workable public IP address with the device. Therefore, the device supports the receipt of STUN binding requests for connectivity checks of ICE candidates and responds with STUN responses. Note that in the response to the INVITE message received from the remote endpoint, the device sends only a single candidate for its' IP address. This is the IP address of the device that the client uses.

The following figure shows an example of using ICE-Lite when the device communicates with a WebRTC client:

■

ICE-Full: When configured for ICE-Full, the device can play the role as ICE controlled or ICE controlling. The device initiates STUN negotiation for all candidate pairs. The device sends the candidates with its local IP address, and a public IP address if configured in the NAT Translation table (see Configuring NAT Translation per IP Interface). The device sends keep-alive messages to keep NAT bindings open for media sessions using ICE-Full.

The following figure shows an example of using ICE-Full, whereby the SBC device sends two candidates, one with its local IP address and one with its public IP address, according to its NAT Translation table.

To support ICE, the device's leg interfacing with the ICE-enabled client (SIP entity) must be enabled for ICE. This is done by using the IP Profile parameter 'ICE Mode' (see Configuring IP Profiles), which can be configured to Lite or Full.